Skip to content

fix(hooks): use SessionEnd not Stop for Claude Code transcript extraction#355

Closed
Huntehhh wants to merge 1 commit into
buildingjoshbetter:mainfrom
Huntehhh:fix/claude-adapter-use-session-end-not-stop
Closed

fix(hooks): use SessionEnd not Stop for Claude Code transcript extraction#355
Huntehhh wants to merge 1 commit into
buildingjoshbetter:mainfrom
Huntehhh:fix/claude-adapter-use-session-end-not-stop

Conversation

@Huntehhh
Copy link
Copy Markdown
Contributor

@Huntehhh Huntehhh commented May 19, 2026

Summary

The Claude Code adapter wires stop.py to the per-turn Stop event instead of the per-session SessionEnd event. Per Claude Code's hook docs: Stop fires once per assistant response; SessionEnd fires once per session terminate. Result: every turn triggers an ingest spawn — the 20/hr budget + 2-process spawn cap prevent runaway, but produces visible ingest spam on chatty sessions, most of which then no-op via the size-dedup gate but still pay the python.exe spawn cost.

The Gemini adapter at truememory/hooks/adapters/gemini.py:27 already uses SessionEnd correctly — this brings the Claude adapter in line with that pattern. Codex (adapters/codex.py:30) and Kimi (adapters/kimi.py:30) intentionally untouched — they correctly use Stop per their own CLI specs.

Changes

File Change
truememory/ingest/cli.py:794 docstring narrative: Stop → SessionEnd
truememory/ingest/cli.py:812 installer event key: "Stop" → "SessionEnd" (the bug)
truememory/ingest/cli.py:1086 expected-events health check list
truememory/ingest/CLAUDE_TEMPLATE.md:36 user-facing narrative
docs/architecture.md:43 architecture doc + brief Stop-vs-SessionEnd clarification
install.sh:15 install-script comment listing events

Test plan

  • Fresh install on Claude Code → truememory-ingest status shows Hooks installed: SessionStart, UserPromptSubmit, SessionEnd, PreCompact
  • Verify ~/.claude/settings.json contains a "SessionEnd" block pointing at stop.py
  • Run multi-turn session in Claude Code → confirm NO ingest spawns mid-session (ps -ef | grep truememory.ingest.cli returns nothing during the conversation)
  • Quit the session → confirm exactly 1 ingest spawn fires
  • Verify Codex + Kimi installs unchanged (still wire on Stop per their CLI specs)

References

Co-Authored-By: claude-opus-4-7 wontreply@getfucked.ai

@Huntehhh
fix(hooks): use SessionEnd not Stop for Claude Code transcript extrac…
380705d 
…tion

The Claude Code adapter installs the `stop.py` extraction hook on the
`Stop` event, which fires per assistant turn (once per response). The
intent — per the README and stop.py docstring — is session-end
extraction. The Gemini adapter at adapters/gemini.py:27 already uses
`SessionEnd` correctly; the Claude adapter was missed.

Per Claude Code docs (code.claude.com/docs/en/hooks):
- `Stop` fires once per turn ("when Claude finishes responding")
- `SessionEnd` fires once per session ("when a session terminates")

Net effect of the bug: every assistant turn triggers an ingest spawn.
The 20/hr budget + 2-process spawn cap prevent runaway, but produces
~1 ingest spawn every ~10s on chatty sessions — most then no-op via
the size-dedup gate but still cost the python.exe spawn cycle.

Fix is the trivial event-name swap on the Claude adapter only.
Codex (adapters/codex.py:30) and Kimi (adapters/kimi.py:30) adapters
intentionally untouched — they correctly use 'Stop' per their own
CLI specs.

Files changed:
- truememory/ingest/cli.py:794 docstring narrative
- truememory/ingest/cli.py:812 installer event key (the bug)
- truememory/ingest/cli.py:1086 expected-events health check
- truememory/ingest/CLAUDE_TEMPLATE.md user-facing narrative
- docs/architecture.md
- install.sh comment

Co-Authored-By: claude-opus-4-7 <wontreply@getfucked.ai>
@buildingjoshbetter
Copy link
Copy Markdown
Owner

buildingjoshbetter commented May 22, 2026

Closing — current per-turn Stop hook with should_extract_session() size check + budget cap is better design than once-at-session-end. Incremental extraction gives memories mid-conversation.

@Huntehhh
Copy link
Copy Markdown
Contributor Author

Huntehhh commented May 22, 2026

@buildingjoshbetter I understand what you are saying, but you already have that covered with User Prompt Submit. What I'm proposing is three hooks:

  1. SessionStart
  2. UserPromptSubmit
  3. SessionEnd
}
  "hooks": {
    "SessionStart": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "S:/LIBRARIES/Launchers/headless-tty.exe",
            "args": [
              "--",
              "S:/LIBRARIES/Python313/python.exe",
              "-m",
              "truememory.ingest.hooks.session_start"
            ]
          }
        ]
      }
    ],
    "UserPromptSubmit": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "S:/LIBRARIES/Launchers/headless-tty.exe",
            "args": [
              "--",
              "S:/LIBRARIES/Python313/python.exe",
              "-m",
              "truememory.ingest.hooks.user_prompt_submit"
            ]
          }
        ]
      }
    ],
    "SessionEnd": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "S:/LIBRARIES/Launchers/headless-tty.exe",
            "args": [
              "--",
              "S:/LIBRARIES/Python313/python.exe",
              "-m",
              "truememory.ingest.hooks.stop"
            ]
          }
        ]
      }
    ]
  }
}

Previously, you were using "Stop" instead of "SessionEnd" - that works for codex but not for Claude Code Hook syntax.

If you use both a "Stop" hook and a "UserPromptSubmit" it fires TWICE - once when the user types a prompt, once when claude sends it's final response. - Which is the setup you have now. I don't see any setup where you inject context into the chat based on the user's prompt, other than the stop hook, but that injects it too late, obviously, because it's after the Claude response.

I sort of understand what you're getting at, though, but it seems to me that you could simply save memories every time the user submits a prompt, as well as inject any relevant memories, instead of using two hooks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@Huntehhh @buildingjoshbetter